Forum des exercices du projet Zuul

Exercice 7.49.1 (OPTIONNEL)

  
 
Avatar Denis BUREAU
Exercice 7.49.1 (OPTIONNEL)
par Denis BUREAU, mardi 19 novembre 2013, 15:42
 

Expliquer l'utilisation (s'il y a lieu) de l'héritage entre les classes Item, Player, Character, et pourquoi pas SpecialCharacter (voir les exercices 9.10 et 9.11 du livre).

Avatar Denis BUREAU
Re: Exercice 7.49.1 (OPTIONNEL)
par Denis BUREAU, samedi 7 décembre 2013, 19:19
 

Un étudiant a écrit :

Bonjour, vu la proximité entre un Player et un Character, je pense que Character peut hériter de Player. Est-ce correct ?

Cordialement.

Avatar Denis BUREAU
Re: Exercice 7.49.1 (OPTIONNEL)
par Denis BUREAU, samedi 7 décembre 2013, 19:22
 

Ne trouvez-vous pas qu'il y a pas mal de choses dans Player qui ne serviront pas à Character ?

Ne vaudrait-il pas mieux que Player hérite de Character ?

Sauf s'il y a des choses dans Character qui ne servent pas à Player. Dans ce cas, comment peut-on utiliser malgré tout l'héritage ?

Avatar Jean COULOM
Re: Exercice 7.49.1 (OPTIONNEL)
par Jean COULOM, dimanche 8 décembre 2013, 11:15
 

Ah, j'avais l'impression que Character avait des fonctionnalités plus spécifiques qu'un player. 

Du coup pour utiliser malgré tout l'héritage, on peut déclarer des méthodes de Character inutiles pour Player private pour en empêcher l'héritage.

Avatar Denis BUREAU
Re: Exercice 7.49.1 (OPTIONNEL)
par Denis BUREAU, dimanche 8 décembre 2013, 18:04
 

Attention : l'héritage ne doit être utilisé que si cela a un sens, c'est-à-dire qu'on peut dire que A est une sorte de B.

Il ne s'agit pas d'affirmer qu'un Item est une sorte de Room juste parce qu'elles ont un attribut aDescription en commun par exemple ...

Puisque vous devez constater que Player possède des caractéristiques qui n'ont pas de sens pour Character et vice-versa, mais que ces deux classes ont des caractéristiques communes, comment peut-on quand-même utiliser l'héritage dans cette situation ?

Avatar Jean COULOM
Re: Exercice 7.49.1 (OPTIONNEL)
par Jean COULOM, mardi 10 décembre 2013, 17:01
 

Je ne vois pas vraiment comment faire. A part déclarer des attributs static pour empêcher leur réécriture dans la sous-classe. Ou encore faire une classe abstraite ou même une interface qui reprend les choses qui sont pareilles dans player et character et du coup avoir player et character qui heritent ou implementent la même base de méthodes et d'attributs.

Avatar Denis BUREAU
Re: Exercice 7.49.1 (OPTIONNEL)
par Denis BUREAU, mardi 10 décembre 2013, 17:52
 

"Je ne vois pas vraiment comment faire."

??? vous prouvez le contraire ci-dessous ...

"... faire une classe abstraite ... qui reprend les choses qui sont pareilles dans player et character et du coup avoir player et character qui heritent ... la même base de méthodes et d'attributs."

pourquoi cette idée ne vous convient-elle pas ?

Avatar Jean COULOM
Re: Exercice 7.49.1 (OPTIONNEL)
par Jean COULOM, mardi 10 décembre 2013, 18:07
 

Je me suis rendu compte que c'était pas si idiot en l'écrivant. Merci :)

Avatar Victor OU
Re: Exercice 7.49.1 (OPTIONNEL)
par Victor OU, dimanche 15 décembre 2013, 13:00
 

Bonjour, je voulais savoir s'il était vraiment nécessaire de faire cet héritage ou non?

Avatar Denis BUREAU
Re: Exercice 7.49.1 (OPTIONNEL)
par Denis BUREAU, dimanche 15 décembre 2013, 15:46
 

du point de vue de la notation, c'est optionnel

du point de vue de la "bonne programmation", c'est souhaitable